IBIS Macromodel Task Group Meeting date: 06 December 2016 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai * Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: Walter Katz Todd Westerhoff Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Bob Ross noted that he wanted to discuss BIRDs 184.1, 185.1, and 186. At the last Open Forum meeting Bob had moved to have BIRDs 184.1 and 185.1 sent back to the ATM group to review feedback from Michael Mirmak, and the motion had passed. ------------- Review of ARs: - Walter to put draft 6 of the file name relaxation proposal into BIRD format and submit it to the IBIS Open Forum. - Done. Submitted as BIRD 186. - Bob M. to submit BIRD 147.4 draft 5 to the IBIS Open Forum as BIRD 147.4. - Done. - Michael M. to incorporate discussed changes into the Deterministic Noise Support BIRD draft and send out draft 3. - Done. Posted to the work archives. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Bob M.: Motion to approve the minutes. - Bob R.: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: Rx Deterministic Noise Support in AMI: - Discussion: Ambrish noted that he had discussed the most recent (draft 3) version of the proposal with his co-workers. He said that he had received some questions as to why the parameter names deviated from simple naming conventions like random and deterministic. Michael M. noted that his first draft of the proposal had used Rx_Rn as an alias for the existing Rx_noise and Rx_Dn for the new deterministic (uniform) noise. Radek noted that we could choose any naming convention we liked, but it would be nice to stay within any existing terminology. Radek noted that deterministic was commonly used with jitter, but that noise was random by nature. Radek said he was not aware of deterministic generally being used with noise. Curtis said he thought the names the group had agreed upon for draft 3, Rx_UnboundedGaussianNoise and Rx_BoundedUniformNoise were unwieldy. He thought the only reason for explicitly stating both unbounded and Gaussian, or bounded and uniform, in the names was to ensure that if new noise types were added in the future there would be no risk of a name collision or confusion. However, he stated that having bounded and unbounded in the names was strange because they were redundant. Radek agreed that they were certainly redundant. Ambrish said he disliked having the redundant terms in the lengthy parameter names. Michael M. said he would be happy to create a draft 4 that changed the names to Rx_GaussianNoise and Rx_UniformNoise. Format and Usage Out Clarifications BIRD: - Michael M.: [sharing draft 3] - Discussion: Michael M. noted that this draft had eliminated all references to "data passed to the executable", and now talked about the "arrangement of data being presented to the EDA tool". It also contained some text discussing Dep parameters. Radek noted that comments from the last meeting, that Dep and Out were treated identically with respect to Format, were properly captured in the last sentence of the paragraph describing Format. However, the second sentence of the paragraph still mistakenly described Dep as being treated the same way as In and InOut. Michael M. said he would correct that sentence and put the proposal into the proper BIRD format. Arpad and Bob R. asked if the modified proposal should be submitted to the Open Forum. Michael M. said he would like to send out one more draft, and he asked people to review it carefully before next ATM meeting. BIRD 184.1, discussion of Michael M.'s feedback - Bob R.: [sharing BIRD 184.1] - I agree with two of Michael's proposed editorial changes: - must -> shall - Adding a sentence in "Usage Rules" noting that the "pin name" column is referred to as "pin_name" elsewhere. - I am concerned about the suggestion to allow the pin name column to be 13 characters wide instead of 5. - It would have ripple effects in many areas. - Michael M.: I'm willing to withdraw that particular suggestion. - It would touch other keywords and interact with BIRD 185. - Bob R.: [referring to] "All pins on a component shall be specified." - Michael points out that this is unenforceable. - I would replace "shall" with "should". - One question is whether this should fall under the [Component] keyword. - We could state there that it should list all pins for a full description of the component. - I think it's really up to the model maker to decide. - Radek: We could say something like, "The pins listed under the [Pin] keyword define all the pins in a component that are described by this file." - Bob R.: Or, "For a full component description, all pins on a component should be specified." - The important change is "should" instead of shall. - Bob R.: Michael also suggests that we introduce "columns" as opposed to Sub-Params under the [Pin] keyword (and [Diff Pin] and [Pin Mapping]). - Arpad: Is there anything broken that we need to fix with this change? - Michael M: It's a minor point. I'm willing to withdraw this suggestion, too. - This may come back to bite us later if we continue to introduce multi-argument tokens. - We may want to be more precise between "columns" and Sub-Params. - The change would only affect 3 keywords and shouldn't affect the parser. - Bob: It's a simple valid change, but it propagates through IBIS because we use the word column in many places. - In some places we may mean an entry in a column. For example, I-V tables like [Pullup] have a V column and then typ, min, max I columns. - Radek: If they were true Sub-Params, then the column headings for signal_name, model_name, R, L, C could appear in any order and be processed that way. - Bob R.: You're right. We don't explicitly state the rule. - I think the order is signal_name, model_name, but then the R, L, C can technically appear in any order. - Radek: In that case Sub-Params is probably a more precise name than "columns". - Bob R.: The bottom line is that if we want to do something like this I'd prefer to push it off into another BIRD. - Michael M.: No objection. - Bob R.: I'll issue a BIRD 184.2 draft with the editorial changes we discussed. - I will also add a comment stating that the changes in BIRD 184.2 supersede language in BIRD 180, with one exception. BIRD 185.1, discussion of Michael M.'s feedback - Bob R.: [sharing BIRD 185.1] - I agree with Michael's two proposed editorial changes: - Extra comma at the end of the NA line in item 2 should be removed. - The colon at the end of the new text should be a period. - I have the same concerns I mentioned earlier about the proposal to increase the length of the pin name column to 13 characters. - One motivation for making the change was to be able to get rid of the CIRCUITCALL exception. - Michael M.: I withdraw that suggestion. We can fix that later. It is easy to remove the exception sentence later. - Bob R.: I'll issue a BIRD 185.2 draft with the editorial changes we discussed. BIRD 186 File Naming Rules: - Discussion: Bob noted that he had searched the IBIS spec for "file name" and encountered a different context. In section 7, PACKAGE MODELING, the Package model files are listed as ".pkg". This extension shown after the is counter to the discussion in section 3. We might therefore have to make changes in the Package Modeling, EBD, and multi-lingual sections. Searching for uses of "extension", we also have ".pkg" defined as an extension, where in section 3 the extension is the part after the period. We might have more ripple effect to cleanup with BIRD 186. Arpad noted that this might be an editorial discussion better suited to another forum. - Michael M.: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Michael M. to incorporate discussed changes into the Deterministic Noise Support BIRD draft and send out draft 4. AR: Michael M. to incorporate discussed changes into the Format and Usage Out Clarifications BIRD draft and send out draft 4. AR: Bob R. to incorporate discussed changes and send out BIRD 184.2 draft 1. AR: Bob R. to incorporate discussed changes and send out BIRD 185.2 draft 1. ------------- Next meeting: 13 December 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives